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(57) Computer apparatus comprising a receiver for 
receiving an integrity metric for a computer entity via a 
trusted device associated with the computer entity, the 
integrity metric having values for a plurality of charac- 
teristics associated with the computer entity; a controller 
for assigning a trust level to the computer entity from a 
plurality of trust levels, wherein the assigned trust level 
is based upon the value of at least one of the character- 
istics of the received integrity metric. 
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Description 

Technical Field 

[0001] The present invention relates to the determin- 
ing of trust levels for a computer entity. 



Background Art 

[0002] A modern computing apparatus includes many 
different components, otherwise known as entities, (the 
word "component" and "entity" is used here to describe 
essentially any discrete functional element of a comput- 
ing platform, including either a piece of hardware, a 
piece of software or a piece of firmware), most of which 
are standardized and can be upgraded. Alternatively, 
the use of computer entity can refer to a computer plat- 
form comprising a plurality of components. 
[0003] EP patent application 99301100.6 describes 
the use of a Trusted Component (TC), also known as 
a trusted device (TD), to enable verification of the integ- 
rity of computing apparatus by the reliable measure- 
ment and reliable reporting of integrity metrics. This en- 
ables the verification of the integrity of computer appa- 
ratus by either a local user or a remote entity. EP patent 
application 99301100.6 describes a general method of 
reporting integrity metrics and verifying the correctness 
of the integrity of computing apparatus by comparing re- 
ported values of metrics with verified values of metrics. 
This solution allows an apparatus* challenger (where a 
challenger is defined as a local or remote device possi- 
bly operating on behalf of a human user) to challenge 
the trusted device in order to check the integrity of one 
or more particular component. The trusted device re- 
sponds to the challenge by sending a signed report of 
the one or more particular components. The report in- 
cludes information about the components, such as the 
model of a component, the manufacturer of a compo- 
nent, the version of a component, upgraded data and 
so on. After receiving the report, the challenger makes 
a decision on whether or not to trust a particular com- 
ponent, and furthermore after checking a number of se- 
lected functional components, the challenger will make 
a decision whether or nor to trust the computing appa- 
ratus. 

[0004] One useful feature, which has not been cov- 
ered by this prior art solution, is how the challenger of 
the computing apparatus is able to make its own deci- 
sion easily and how those decisions can be dealt with 
in a flexible manner. 

[0005] It is desirable to improve this situation. 
Summary of the Invention 

[0006] I n accordance with a first aspect of the present 
invention there is provided a computer apparatus com- 
prising a receiver for receiving an integrity metric for a 
computer entity via a trusted device associated with the 



computer entity, the integrity metric having values for a 
plurality of characteristics associated with the computer 
entity; a controller for assigning a trust level to the com- 
puter entity from a plurality of trust levels, wherein the 
s assigned trust level is based upon the value of at least 
one of the characteristics of the received integrity metric. 
[0007] Preferably the trusted device is arranged to ac- 
quire an integrity metric of the computer entity. 
[0008] Preferably the trust level is determined by com- 
10 paring the value of the at least one characteristics with 
a specified value. 

[0009] Preferably the plurality of trust levels are de- 
termined base upon a plurality of specified values asso- 
ciated with a plurality of characteristics of a computer 
1 $ entity. 

[0010] Preferably the plurality of trust levels are de- 
termined based upon a plurality of specified values as- 
sociated with characteristics for a plurality of computer 
entities. 

2° [0011] In accordance with a second aspect of the 
present invention there is provided a method of assign- 
ing a trust level, the method comprising receiving an in- 
tegrity metric for a computer entity via a trusted device 
associated with the computer entity, the integrity metric 

25 having values for a plurality of characteristics associat- 
ed with the computer entity; assigning a trust level to the 
computer entity from a plurality of trust levels, wherein 
the assigned trust level is based upon the value of at 
least one of the characteristics of the received integrity 

30 metric. 

[0012] This invention extends the prior art solution of 
integrity checking of selected components within the 
computing apparatus, and allows the user to implement 
its own policy related to integrity checking. 

35 [0013] The recording of all or some of the related in- 
formation of a functional component of a computing ap- 
paratus can be performed efficiently and completely. 
The information stored can include a full history of the 
component as well as the component's current value. 

40 [0014] A policy database can be established by listing 
the configuration of functional components and related 
information. 

[0015] The policy list can be stored in a secure man- 
ner, if required. For example, by storing the policy spe- 
45 cific parameters using either a trusted token or other 
computing apparatus of the user or the protected stor- 
age of the computing apparatus. 

[0016] This invention relates to the integrity checking 
of functional components in a computing apparatus and 

50 how this measurement can be used by a user in estab- 
lishing trustworthiness of a computing apparatus based 
on the policy established by the user of the apparatus. 
[0017] The method proposed in this invention allows 
the user of a computing apparatus, both remote and lo- 

55 cal, to establish trust on the apparatus before exchang- 
ing data. 
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Brief Description of the Drawings 

[0018] Preferred embodiments of the present inven- 
tion will now be described, by way of example only, with 
reference to the accompanying drawings, of which: 

Figure 1 is a diagram that illustrates a system ca- 
pable of implementing embodiments of the present 
inventio; 

Figure 2 is a diagram, which illustrates a mother- 
board including a trusted device arranged to com- 
municate with a smart card via a smart card reader 
and with a group of functional components; 
Figure 3 is a diagram that illustrates the trusted de- 
vice in more detail; 

Figure 4 is a flow diagram that illustrates the steps 
involved in acquiring an integrity metric of the com- 
puting apparatus; 

Figure 5 is a flow diagram that illustrates the steps 
involved in establishing communications between a 
trusted computing platform and a remote platform 
including the trusted platform verifying its integrity; 
Figure 6 is an illustration of the structure of various 
fields in a CCR component; 

Figure 7 is an illustration of CCR fields with time- 
related information about components 
Figure 8 is a diagram that illustrates the database 
of characteristics of functional components made 
by the user. 

Figure 9 is a diagram that illustrates the database 
prepared by a user for parameters to be checked 
for each trust level. 

Description of the Preferred Embodiment 

[001 9] As described in detail below, a trusted platform 
has as its central feature the incorporation into a com- 
puting platform of a physical trusted device whose func- 
tion is to bind the identity of the platform to reliably meas- 
ured data that provides an integrity metric of the plat- 
form. The identity and the integrity metric are compared 
with expected values provided by a trusted party (TP) 
that is prepared to vouch for the trustworthiness of the 
platform. If there is a match, the implication is that at 
least part of the platform is operating correctly, depend- 
ing on the scope of the integrity metric. 
[0020] A user verifies the correct operation of the plat- 
form before exchanging other data with the platform. A 
user does this by requesting the trusted device to pro- 
vide its identity and an integrity metric. The identity met- 
ric of the platform as a whole can be obtained by obtain- 
ing the identity metric of the individual critical compo- 
nents of the platform from their respective component 
configuration registers (CCRs). (Optionally the trusted 
device will refuse to provide evidence of identity if it itself 
was unable to verify correct operation of the compo- 
nents of the platform.) The user receives the proof of 
identity and the identity metrics of the individual compo- 



nents, and compares them against values that it be- 
lieves to be true. Those proper values are provided by 
the TP or another entity that is trusted by the user or can 
be set by the user himself. By interpreting the compo- 

5 nent configuration values (CCV) associated with the 
CCRs, and comparing these values with the standard 
set in his policy, the user determines what level of trust 
to attach with that platform, as described below. The us- 
er believes the data reported by the trusted device (TC) 

10 because it has validated its identity. 

[0021] Once a user has established a level of trust 
with the operation of the platform, he exchanges other 
data with the platform or decides not to exchange data 
with that platform. For a local user, the exchange might 

15 be by interacting with some software application running 
on the platform. For a remote user, the exchange might 
involve a secure transaction. In either case, the data ex- 
changed is 'signed* by the trusted device. The user can 
then have greater confidence that data is being ex- 

20 changed with a platform whose behaviour can be trust- 
ed. 

[0022] A trusted platform 10 is illustrated in the dia- 
gram in Figure 1 . The platform 1 0 includes the standard 
features of a keyboard 14. mouse 16 and visual display 

25 unit (VDU) 1 8, which provide the physical 'user interface' 
of the platform. This embodiment of a trusted platform 
also contains a smart card reader 1 2 - a smart card read- 
er is not an essential element of all trusted platforms, 
but is employed in various preferred embodiments de- 

30 scribed below. Alongside the smart card reader 12, 
there is illustrated a smart card 19 to allow trusted user 
interaction with the trusted platform as shall be de- 
scribed further below. In the platform 1 0, there are a plu- 
rality of modules 15: these are other functional elements 

35 of the trusted platform of essentially any kind appropri- 
ate to that platform. Optionally, instead of a smart card 
and reader, any type of mobile computing apparatus (for 
example, a Personal Digital Assistant) can be used to 
connect to the trusted platform and operate on the user's 

40 behalf as a device that can challenge the trusted plat- 
form, perform computation regarding the trustworthi- 
ness of the computing platform, feed information as to 
the trustworthiness of the computing platform to the user 
or store user profiles. As illustrated in Figure 2, the moth- 

45 erboard 20 of the trusted computing platform 10 in- 
cludes (among other standard components) a main 
processor 21 . main memory 22. a trusted device 24, a 
data bus 26 and respective control lines 27 and lines 28, 
BIOS memory 29 containing the BIOS program for the 

so platform 10 and an Input/Output (IO) device 23, which 
controls interaction between the components of the 
motherboard and the smart card reader 12, the key- 
board 14, the mouse 16 and the VDU 18. The main 
memory 22 is typically random access memory (RAM). 

55 in operation, the platform 1 0 loads the operating system, 
for example Windows NT™, into RAM from hard disk 
(not shown). Additionally, in operation, the platform 10 
loads the processes or applications that may be execut- 
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ed by the platform 1 0 into RAM from hard disk (not 
shown). 

[0023] The trusted device uses cryptographic proc- 
esses but does not necessarily provide an external in- 
terface to those cryptographic processes. Also, a most 
desirable implementation would be to make the trusted 
device tamperproof , to protect secrets by making them 
inaccessible to other platform functions and provide an 
environment that is substantially immune to unauthor- 
ised modification. Since tamper proofing is impossible, 
the best approximation is a trusted device that is tamper- 
resistant, or tamper-detecting. The trusted device, 
therefore, preferably consists of one physical compo- 
nent that is tamper-resistant. Techniques relevant to 
tamper-resistance are well known to those skilled in the 
art of security. 

[0024] The trusted device Is preferably a physical one 
because it must be difficult to forge. It is most preferably 
tamper-resistant because it must be hard to counterfeit. 
It typically has an engine capable of using cryptographic 
processes because it is required to prove identity, both 
locally and at a distance, and it contains at least one 
method of measuring some integrity metric of the plat- 
form with which it is associated. 

[0025] Typically, in a personal computer the BIOS pro- 
gram is located in a special reserved memory area, the 
upper 64K of the first megabyte do the system memory 
(addresses F000h to FFFFh), and the main processor 
is arranged to look at this memory location first, in ac- 
cordance with an industry wide standard. 
[0026] The significant difference between the plat- 
form and a conventional platform is that, after reset, the 
main processor is initially controlled by the trusted de- 
vice, which then hands control over to the platform-spe- 
cific BIOS program, which in turn initialises all input/out- 
put devices as normal. After the BIOS program has ex- 
ecuted, control is handed over as normal by the BIOS 
program to an operating system program, such as Win- 
dows NT (TM), which is typically loaded into main mem- 
ory 22 from a hard disk drive (not shown). 
[0027] Clearly, this change from the normal procedure 
requires a modification to the implementation of the in- 
dustry standard, whereby the main processor 21 is di- 
rected to address the trusted device 24 to receive its first 
instructions. This change may be made simply by hard- 
coding a different address into the main processor 21. 
Alternatively, the trusted device 24 may be assigned the 
standard BIOS program address, in which case there is 
no need to modify the main processor configuration. 
[0028] It is highly desirable for the BIOS boot block to 
be contained within the trusted device 24. This prevents 
subversion of the obtaining of the integrity metric (which 
could otherwise occur if rogue software processes are 
present) and prevents rogue software processes creat- 
ing a situation in which the BIOS (even if correct) fails 
to build the proper environment for the operating sys- 
tem. 

[0029] Although, in the preferred embodiment to be 



described, the trusted device 24 is a single, discrete 
component, it is envisaged that the functions of the trust- 
ed device 24 may alternatively be split into multiple de- 
vices on the motherboard, or even integrated into one 
5 or more of the existing standard devices of the platform. 
For example, it is feasible to integrate one or more of 
the functions of the trusted device into the main proces- 
sor itself, provided that the functions and their commu- 
nications cannot be subverted. This, however, would 
10 probably require separate leads on the processor for 
sole use by the trusted functions. Additionally or alter- 
natively, although in the present embodiment the trusted 
device is a hardware device that is adapted for integra- 
tion into the motherboard 20, it is anticipated that a trust- 
's ed device may be implemented as a 'removable' device, 
such as a dongle, which could be attached to a platform 
when required. Whether the trusted device is integrated 
or removable Is a matter of design choice. However, 
where the trusted device is separable, a mechanism for 
20 providing a logical binding between the trusted device 
and the platform should be present. 
[0030] The trusted device 24 comprises a number of 
blocks, as illustrated in Figure 3. After system reset, the 
trusted device 24 performs a secure boot process to en- 
25 sure that the operating system of the platform 10 (in- 
cluding the system clock and the display on the monitor) 
is running properly and in a secure manner. During the 
secure boot process, the trusted device 24 acquires an 
integrity metric of the computing platform 1 0. The trust- 
30 ed device 24 can also perform secure data transfer and, 
for example, authentication between it and a smart card 
via encryption/decryption and signature/verification. 
The trusted device 24 can also securely enforce various 
security control policies, such as locking of the user in- 
35 terface. 

[0031] Specifically, the trusted device comprises: a 
controller 30 programmed to control the overall opera- 
tion of the trusted device 24, and interact with the other 
functions on the trusted device 24 and with the other 

40 devices on the motherboard 20; a measurement func- 
tion 31 for acquiring the integrity metricfrom the platform 
10; a cryptographic function 32 for signing, encrypting 
or decrypting specified data; an authentication function 
33 for authenticating a smart card; and interface circuitry 

45 34 having appropriate ports (36, 37 & 38) for connecting 
the trusted device 24 respectively to the data bus 26, 
control lines 27 and address lines 28 of the motherboard 
20. Each of the blocks in the trusted device 24 has ac- 
cess (typically via the controller 30) to appropriate vol- 

50 atile memory areas 4 and/or non-volatile memory areas 
3 of the trusted device 24. Additionally, the trusted de- 
vice 24 is designed, in a known manner, to be tamper 
resistant. 

[0032] For reasons of performance, the trusted device 
55 24 may be implemented as an application specific inte- 
grated circuit (ASIC). However, for flexibility, the trusted 
device 24 is preferably an appropriately programmed 
micro-controller. Both ASICs and micro-controllers are 
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well known in the art of microelectronics and will not be 
considered herein in any further detail. 
[0033] One item of data stored in the non-volatile 
memory 3 of the trusted device 24 is a certificate 350. 
The certificate 350 contains at least a public key 351 of 5 
the trusted device 24 and an authenticated value 352 of 
the platform integrity metric measured by a trusted party 
(TP). The certificate 350 is signed by the TP using the 
TP's private key prior to it being stored in the trusted 
device 24. In later communications sessions, a user of 
the platform 1 0 can verify the integrity of the platform 1 0 
by comparing the acquired integrity metric with the au- 
thentic integrity metric 352. If there is a match, the user 
can be confident that the platform 1 0 has not been sub- 
verted. Knowledge of the TP's generally-available pub- 
lic key enables simple verification of the certificate 350. 
The non-volatile memory 35 also contains an identity 
(ID) label 353. The ID label 353 is a conventional |D la- 
bel, for example a serial number, that is unique within 
some context. The ID label 353 is generally used for in- 
dexing and labelling of data relevant to the trusted de- 
vice 24, but is insufficient in itself to prove the identity of 
the platform 1 0 under trusted conditions. 
[0034] The trusted device 24 is equipped with at least 
one method of reliably measuring or acquiring the integ- 
rity metric of the computing platform components 1 0. In 
the present embodiment, the integrity metric is acquired 
by the measurement function 31 by generating a digest 
of the BIOS instructions in the BIOS memory. Such an 
acquired integrity metric, if verified as described above, 
gives a potential user of the platform 10a high level of 
confidence that the platform 1 0 has not been subverted 
at a hardware, or BIOS program, level. Other known 
processes, for example virus checkers, will typically be 
in place to check that the operating system and appli- 
cation program code has not been subverted. 
[0035] The measurement function 31 has access to: 
non-volatile memory 3 for storing a hash program 354 
and a private key 355 of the trusted device 24, and vol- 
atile memory 4 for storing acquired integrity metric in the 
form of a digest 361 . The integrity values of individual 
components of the computing apparatus are stored in a 
Component Configuration Register (CCR). Each single 
component of the apparatus will have a CCR with its 
integrity values: Component Configuration Values 
(CCV). The CCV will include the current configuration 
details of the component and also the previously modi- 
fied values of the component. Thus the CCR records the 
complete history of a component, however storing the 
complete history of a component is not a necessity. Stor- 
ing the history enables a user to check the current infor- 
mation of a component and also the past record of the 
component before it decides about the trustworthiness 
of that component. The number of CCRs in a computing 
apparatus is optional. Theoretically a computing appa- 
ratus will have as many CCRs as there are components 
in the apparatus. Also, theoretically, different CCRs in a 
computing appliance will have different sizes. But from 



the point of simplicity and efficiency, it is best to keep 
the size of CCRs in a computing appliance the same. 
[0036] Any computing apparatus should have a min- 
imum number of CCRs to hold information about the crit- 
ical components. There is, as has been stated earlier, 
no upper limit of CCRs in a computing apparatus. 
[0037] Preferably a CCR is available for each of the 
following components: 

1 . BIOS 

2. Optional ROM 

3. OS Loader 

4. Operating System 

[0038] So preferably there are at least four CCRs, one 
for each of the above components, in any computing ap- 
paratus. 

[0039] Figure 6 shows an example of the fields of a 
CCR, where the fields in a CCR together form the Com- 
ponent Configuration value (CCV). Additional fields can 
be optionally added, if required. The fields are: 

701 CCR Contents (e.g. BIOS, OS, OS Loader etc.) 

702 CCR index 

703 Certificate information 

704 Last update (this can be a p re-specified value, 
say 0 for reset, 1 for Boot etc) 

705 Latest update version 

706 Previous update 

[0040] The CCR Content 701 can be used to mention 
the name of the software/hardware component of the 
platform about which the CCR stores information. 
[0041 ] The CCR index 702 gives the index number of 
the CCR 

[0042] For simplicity purposes, the CCR index 702 
and CCR content 701 can be standardized. That means, 
a particular index number will always identify a particular 
component. In that case it is advisable to keep the CCR 
index 702 as a mandatory field. Again this is not man- 
datory while implementing but just a suggestion for sim- 
plification. Users can choose to carry out this implemen- 
tation differently. 

[0043] An example of the above mentioned idea is: 

CCR index 1 will refer to BIOS information 
CCR index 2 will always refer to Optional ROM. 

[0044] Every component of the platform can have its 
own certificate for the purpose of authenticity. The cer- 
tificate field 703 in the CCR register will hold information 
of the certificate of that component. 
[0045] The last update 704 of that CCR can be a pre- 
determined update indicator such as 0,1. ...etc. For ex- 
ample - 0 for update by reset and 1 for update by boot . 
[0046] The latest update version field 705 can contain 
a hash of the latest updated version/ information of the 
software/hardware component. 
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[0047] The previous update field 706 stores informa- 
tion about all previous information that were stored in 
the CCR, before the latest CCR value was loaded. This 
field acts as the history of the CCR. 
[0048] The idea is to allow the user to look at the his- 
tory of the components, which in other words means the 
history of the platform, before determining whether that 
particular component can be trusted or not; and if to be 
trusted, to what degree. 

[0049] For example, a particular CCR might have 
been updated 50 times but the security policy might re- 
quire checking only the last 15 update values for making 
a trust-related decision. The history is stored in such a 
flexible and efficient way that the user can extract any 
number of previous CCV values (history). 
[0050] To provide a minimum level of information 
about a particular component, typically the following 
fields will in a CCR: 



1 . CCR contents or CCR index 

2. Last update version 

[0051] The above fields allows a user to associate a 
CCR to its respective component and also provides the 
present value of the CCR. 

[0052] Figure 7 illustrates an alternative structure of 
a CCR which stores component information in relation 
to time. For example, a user's policy might require to 
obtain all information about a particular component over 
the last 24 hours. 

[0053] For this purpose, in addition to storing CCR 
values with respect to every update event, there should 
be a mechanism to store CCR values with respect to a 
time frame (t). 

In that case the CCR fields will be: 

801 CCR index 

802 CCR Contents (eg. BIOS, OS, OS Loader etc ) 

803 Certificate 

804 Last update N 

805 Last update time H(t) 

806 Latest update version 
' 807 Previous update (History) with respect to up- 
date K 

808 Previous update (History) with respect to time 

[0054] In appropriate embodiments, the volatile mem- 
ory 4 may also be used to store the public keys and as- 
sociated ID labels 360a-360n of one or more authentic 
smart cards 1 9s that can be used to gain access to the 
platform 10. 

[0055] In one preferred implementation, as well as the 
digest, the integrity metric includes a Boolean value, 
which is stored in volatile memory 4 by the measure- 
ment function 31 , for reasons that will become apparent. 
[0056] A preferred process for acquiring an integrity 
metric will now be described with reference to Figure 4. 
[0057] In step 500, at switch-on, the measurement 



function 31 monitors the activity of the main processor 
21 on the data, control and address lines (26, 27 & 28) 
to determine whether the trusted device 24 is the first 
memory accessed. Under conventional operation, a 
5 main processor would first be directed to the BIOS mem- 
ory in order to execute the BIOS program. However, in 
accordance with the present embodiment: the main 
processor 21 is directed to the trusted device 24, which 
acts as a memory. In step 505, if the trusted device 24 
» is the first memory accessed, in step 51 0, the measure- 
ment function 31 writes to volatile memory 3 a Boolean 
value which indicates that the trusted device 24 was the 
first memory accessed. Otherwise, in step 515. the 
measurement function writes a Boolean value which in- 
15 dicates that the trusted device 24 was not the first mem- 
ory accessed. 

[0058] In the event the trusted device 24 is not the first 
accessed, there is of course a chance that the trusted 
device 24 will not be accessed at all. This would be the 
20 case, for example, if the main processor 21 were ma- 
nipulated to run the BIOS program first. Under these cir- 
cumstances, the platform would operate, but would be 
unable to verify its integrity on demand, since the integ- 
rity metric would not be available. Further, if the trusted 
25 device 24 were accessed after the BIOS program had 
been accessed, the Boolean value would clearly indi- 
cate lack of integrity of the platform. 
[0059] In step 520, when (or if) accessed as a memory 
by the main processor 21 , the main processor 21 reads 
50 the stored native hash instructions 354 from the meas- 
urement function 31 in step 525. The hash instructions 
354 are passed for processing by the main processor 
21 over the data bus 26. In step 530, main processor 21 
executes the hash instructions 354 and uses them, in 
35 step 535, to compute a digest of the BIOS memory 29, 
by reading the contents of the BIOS memory 29 and 
processing those contents according to the hash pro- 
gram. In step 540, the main processor 21 writes the 
computed digest 361 to the appropriate non-volatile 
40 memory location 4 in the trusted device 24. The meas- 
urement function 31, in step 545, then calls the BIOS 
program in the BIOS memory 29, and execution contin- 
ues in a conventional manner. 

[0060] Clearly, there are a number of different ways 
^5 in which the integrity metric may be calculated, depend- 
ing upon the scope of the trust required. The measure- 
ment of the BIOS program's integrity provides a funda- 
mental check on the integrity of a platform's underlying 
processing environment. The integrity metric should be 
50 of such a form that it will enable reasoning about the 
validity of the boot process - the value of the integrity 
metric can be used to verify whetherthe platform booted 
using the correct BIOS. Optionally, individual functional 
blocks within the BIOS could have their own digest val- 
55 ues, with an ensemble BIOS digest being a digest of 
these individual digests. This enables a policy to state 
which parts of BIOS operation are critical for an intended 
purpose, and which are irrelevant (in which case the in- 
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dividual digests must be stored in such a manner that 
validity of operation under the policy can be estab- 
lished). 

[0061 J Other integrity checks could involve establish- 
ing that various other devices, components or apparatus 
attached to the platform are present and in correct work- 
ing order. In one example, the BIOS programs associ- 
ated with a SCSI controller could be verified to ensure 
communications with peripheral equipment could be 
trusted. 

[0062] In another example, the integrity of other de- 
vices, for example memory devices or co-processors, 
on the platform could be verified by enacting fixed chal- 
lenge/response interactions to ensure consistent re- 
sults. Where the trusted device 24 is a separable com- 
ponent, some such form of interaction is desirable to 
provide an appropriate logical binding between the trust- 
ed device 14 and the platform. Also, although in the 
present embodiment the trusted device 24 utilises the 
data bus as its main means of communication with other 
parts of the platform, it would be feasible, although not 
so convenient, to provide alternative communications 
paths, such as hard- wired paths or optical paths. Fur- 
ther, although in the present embodiment the trusted de- 
vice 24 instructs the main processor 21 to calculate the 
integrity metric in other embodiments, the trusted device 
itself is arranged to measure one or more integrity met- 
rics. 

[0063] Preferably, the BIOS boot process includes 
mechanisms to verify the integrity of the boot process 
itself. Such mechanisms are already known from, for ex- 
ample, Intel's draft "Wired for Management baseline 
specification v 2.0 - BOOT Integrity Service", and in- 
volve calculating digests of software or firmware before 
loading that software or firmware. Such a computed di- 
gest is compared with a value stored in a certificate pro- 
vided by a trusted entity, whose public key is known to 
the BIOS. The software/firmware is then loaded only if 
the computed value matches the expected value from 
the certificate, and the certificate has been proven valid 
by use of the trusted entity's public key. Otherwise, an 
appropriate exception handling routine is invoked. 
[0064] Optionally, after receiving the computed BIOS 
digest, the trusted device 24 may inspect the proper val- 
ue of the BIOS digest in the certificate and not pass con- 
trol to the BIOS if the computed digest does not match 
the proper value. Additionally, or alternatively, the trust- 
ed device 24 may inspect the Boolean value and not 
pass control back to the BIOS if the trusted device 24 
was not the first memory accessed. In either of these 
cases, an appropriate exception handling routine may 
be invoked. 

[0065] Figure 5 illustrates the flow of actions by a TP, 
the trusted device 24 incorporated into a platform, and 
a user (of a remote platform) who wants to verify the 
integrity of the trusted platform. It will be appreciated 
that substantially the same steps as are depicted in Fig- 
ure 5 are involved when the user is a local user. In either 



case, the user would typically rely on some form of soft- 
ware application to enact the verification. It would be 
possible to run the software application on the remote 
platform or the trusted platform. However, there is a 

5 chance that, even on the remote platform, the software 
application could be subverted in some way. Therefore, 
it is anticipated that, for a high level of integrity, the soft- 
ware application would reside on a smart card (or other 
trusted portable computing device or token) of the user, 

io who would insert the smart card into an appropriate 
reader for the purposes of verification. Figure 5 illus- 
trates the flow of actions for the general case - a more 
specific flow of actions for verification by a user smart 
card will be described with reference to Figure 6 further 

15 below. 

[0066] At the first instance, a TP, which vouches for 
trusted platforms, will inspect the type of the platform to 
decide whether to vouch for it or not. This will be a matter 
of policy. If all is well, in step 600, the TP measures the 

20 value of integrity metric of the platform. Then, the TP 
generates a certificate, in step 605, for the platform. The 
certificate is generated by the TP by appending the trust- 
ed device's public key, and optionally its ID label, to the 
measured integrity metric, and signing thestring with the 

25 TP's private key. 

[0067] The trusted device 24 can subsequently prove 
its identity by using its private key to process some input 
data received from the user and produce output data, 
such that the input/output pair is statistically impossible 

30 to produce without knowledge of the private key. Hence, 
knowledge of the private key forms the basis of identity 
in this case. Clearly, it would be feasible to use symmet- 
ric encryption to form the basis of identity. However, the 
disadvantage of using symmetric encryption is that the 

35 user would need to share his secret with the trusted de- 
vice. Further, as a result of the need to share the secret 
with the user, while symmetric encryption would in prin- 
ciple be sufficient to prove identity to the user, it would 
insufficient to prove identity to a third party, who could 

40 not be entirely sure the verification originated from the 
trusted device or the user. 

[0068] In step 61 0, the trusted device 24 is initialised 
by writing the certificate 350 into the appropriate non- 
volatile memory locations 3 of the trusted device 24. 

45 This is done, preferably, by secure communication with 
the trusted device 24 after it is installed in the mother- 
board 20. The method of writing the certificate to the 
trusted device 24 is analogous to the method used to 
initialise smart cards by writing private keys thereto. The 

50 secure communications is supported by a 'master key', 
known only to the TP, that is written to the trusted device 
(or smart card) during manufacture, and used to enable 
the writing of data to the trusted device 24; writing of 
data to the trusted device 24 without knowledge of the 

55 master key is not possible. 

[0069] At some later point during operation of the plat- 
form, for example when it is switched on or reset, in step 
615, the trusted device 24 acquires and stores the in- 
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tegrity metric 361 of the platform. 
[0070] When a user wishes to communicate with the 
platform, in step 620, he creates a nonce, such as a ran- 
dom number, and, in step 625, challenges the trusted 
device 24 (the operating system of the platform, or an 
appropriate software application, is arranged to recog- 
nise the challenge and pass it to the trusted device 24, 
typically via a BIOS-type call, in an appropriate fashion).' 
The nonce is used to protect the user from deception 
caused by replay of old but genuine signatures (called 
a 'replay attack') by untrustworthy platforms. The proc- 
ess of providing a nonce and verifying the response is 
an example of the well-known 'challenge/response 1 
process. In addition to including a nonce there is also 
included a request for CCR's (CCRreq) associated with 
the platform. 

[0071] The exact contents of CCRreq will depend on 
the security policy of the challenging side, as described 
below. A very strict security policy will require more de- 
tailed CCR information as compared to a policy with very 
low security requirement. 

[0072] The CCRreq may consist of a combination of 



1. CCR indicator (CCR index/CCR content) 

2. CCR certificate/ specific info about certificate re- 
quest 

3. Update information (Last update/Updated ver- 
sion) request 

4. History (Full/ Partial) request. This field will have 
the vatue for H(Dn-l) or H(Dt-l) or both. 

[0073] Typically a CCRreq, has at least two of the 
above two included. One of these is CCR index or any 
other such field as has been implemented to identify a 
CCR. The other one is one of the rest in the above list. 
[0074] The exact number and kind of CCR information 
that is requested by CCRreq totally depends on the us- 
er's security requirement. If a user has a high security 
specification, this might mean he needs more informa- 
tion to decide how much trust to put on the platform. One 
such example is a security requirement that requires the 
total history of CCR and all other information stored in 
the CCR. In this case the CCRreq will have: 

CCR index, certificate, last update, last update 
version, total history of CCR. 

[0075] In step 630, the trusted device 24 receives the 
challenge, including the CCRreq, and creates an appro- 
priate response. This may be a digest of the measured 
integrity metric and the nonce, and optionally its ID label. 
Then, in step 635, the trusted device 24 signs the digest, 
using its private key, and returns the signed digest, ac- 
companied by the certificate 350, to the user where the 
digest includes the CCR information requested. 
[0076] In step 640, the user receives the challenge re- 
sponse and verifies the certificate using the well known 
public key of the TP. The user then, in step 650, extracts 
the trusted device's 24 public key from the certificate 
and uses it to decrypt the signed digest from the chal- 



lenge response. Then, in step 660, the user verifies the 
nonce inside the challenge response. Next, in step 670, 
the user compares the computed integrity metric, which 
it extracts from the challenge response, with the proper 
5 platform integrity metric, which it extracts from the cer- 
tificate. If any of the foregoing verification steps fails, in 
steps 645, 655, 665 or 675, the whole process ends in 
step 680 with no further communications taking place. 
[0077] To allow a user to assign a trust level, from a 
10 plurality of trust levels, the user, in addition to comparing 
the computed integrity metic(s) with the proper platform 
metric (as described above), adopts a security policy, 
as described below. 

[0078] Accordingly, once a successful comparison 
'5 has been achieved, how a user interprets the CCR in- 
formation depends on the users security policy. In some 
cases, it may be required by the challenger to verify the 
CCR certificate. In other cases it might not. The same 
CCR information can be interpreted differently by differ- 
20 ent users having differing security policies. 

[0079] On receiving the CCV, the user compares 
whether it meets the criteria set for that particular com- 
ponent. These criteria are the CCR field values obtained 
from trusted source and stored in a secure storage, for 
25 example a trusted party may stipulated that only a soft- 
ware application of a certain version number, or above, 
can be used. The secured storage is a token like smart- 
card or is any other tamper proof computing apparatus. 
Figure 8 describes the logical structure for storing the 
30 values of each field in CCR form once obtained from the 
trusted source by the user. This list has to be stored in 
a secure storage structure that cannot be subverted by 
physical or logical means. 

[0080] In the Figure 8 component 901 gives the name 
35 of the component and list the various characteristics 902 
of the component which will form the various fields in a 
CCR. The field Value 903 stores the value obtained from 
the trusted source for each of the component. 
[0081] VaLChar 904 gives the value for a particular 
40 characteristic 902 of the component 901 . 

[0082] This set of criteria forms the core of policy da- 
tabase of the user. Every component will have a number 
of characteristics with a specific value. For example, if 
a user wants to use a particular software application, the 
^5 first thing it does is it obtains all the characteristic values 
for that software application from the software vendor. 
It then stores these values in a secure device/applica- 
tion as showed in the Figure 8. 

[0083] Then the user, depending on his requirement, 
50 decides which of the characteristics of this application 
is required to be verified to establish a degree of trust. 
The user can store the list of CCR fields it has to check 
for each component for each trust level in a secure stor- 
age. 

55 [0084] Similarly, for hardware components, it can ob- 
tain all the relevant values/ information from the manu- 
facturer. The user can then decide, based upon a secu- 
rity policy, which of the stored characteristics for this 
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component it needs to verify to establish the degree of 
trust required. 

[0085] In this way, a user can build up a database of 
all the components of a platform that he thinks are nec- 
essary to be verified to establish trust. 5 
[0086] One integral part of the scheme is to take the 
decision when will a computing apparatus be assigned 
a particular trust level. A trust level is assigned to a com- 
ponent of a computing apparatus only when it meets the 
requirement(s) as stored in the policy by the user. This 
requires the user to maintain a database of CCR fields 
to be verified by user to assign trust level to a 
component . The user can have another table listing the 
components and parameters to be verified for each trust 
level. Every characteristic represent a particular filed in 
the CCR of that component. 

[0087] Figure 9 illustrates an example of the type of 
structure that could be used to store component char- 
acteristics to be verified for individual trust levels. The 
idea is to give maximum control to the user. So, depend- 
ing on the sensitivity of the data to be exchanged, it can 
control the parameters of a component to be checked 
to establish trust. For example, before undertaking a fi- 
nancial transaction the user can set the required trust 
level at a higher level, say Trust Level 1 1001 . Then all 
the components and their characteristics listed under 
the table of Trust Level 1 1001 have to be verified to 
establish trust, which in this example are components 
1002, 1003 and 1004. For example, this list of compo- 
nents could be all the components within a device or a 
subset, depending upon a users security policy. Once a 
trust level has been selected the characteristics of the 
relevant components are compared with the information 
provided by the trusted third party, such as software ver- 
sion number. 

[0088] If, for example, only a lower trust level is re- 
quired (e.g. trust level N 1005) less or different compo- 
nent characteristics are compared against the informa- 
tion provided by the trusted third party, for example an 
older version of a software application may be accept- 
able that for level 1 1001. 

[0089] These databases define the trust level in terms 
of components and their characteristics. This way, trust 
can be defined in terms of measurable characteristics 
of components, thus removing it from the level of ab- 
stract. 

[0090] As stated above, the security policy informa- 
tion is desirably stored in secure storage, for example a 
smartcard. 

[0091 ] One of way storing the policy database can be 
using mobile devices with considerable storage capac- 
ity. This will then provide the user the flexibility to use 
any other computing appliance for data exchange, with- 
out compromising his security requirement. 
[0092] Alternatively it can be stored in the computing 
appliance that is usually used by the user for data ex- 
change. 

[0093] Assuming all is well, in steps 685 and 690, the 



user and the trusted platform use other protocols to set 
up secure communications for other data, where the da- 
ta from the platform is preferably signed by the trusted 
device 24. 

[0094] Further refinements of this verification process 
are possible. It is desirable that the challenger becomes 
aware, through the challenge, both of the value of the 
platform integrity metric and also of the method by which 
it was obtained. Both these pieces of information are de- 
sirable to allow the challenger to make a proper decision 
about the integrity of the platform. The challenger also 
has many different options available - it may accept that 
the integrity metric is recognised as valid in the trusted 
device 24, or may alternatively only accept that the plat- 
form has the relevant level of integrity if the value of the 
integrity metric is equal to a value held by the challenger 
(or may hold there to be different levels of trust in these 
two cases). 

[0095] The techniques of signing, using certificates, 
and challenge/response, and using them to prove iden- 
tity, are well known to those skilled in the art of security 
and therefore need not be described in any more detail 
herein. 

[0096] There exist many available challenge/re- 
sponse mechanisms. The implementation of an authen- 
tication protocol used in the present embodiment is mu- 
tual (or3-step) authentication, as described in ISO/IEC 
9798-3 : "Information technology - Security techniques - 
Entity authentication mechanisms; Part 3; Entity au- 
thentication using a public key algorithm", International 
Organization for Standardization, November 1993. Of 
course, there is no reason why other authentication pro- 
cedures cannot be used, for example 2-step or 4-step, 
as also described in this reference. 
[0097] As would be appreciated by a person skilled in 
the art all the CCV fields in the CCR proposed in this 
embodiment are optional. 
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40 Claims 

1 . Computer apparatus comprising a receiver for re- 
ceiving an integrity metric for a computer entity via 
a trusted device associated with the computer enti- 

45 ty, the integrity metric having values for a plurality 
of characteristics associated with the computer en- 
tity; a controller for assigning a trust level to the 
computer entity from a plurality of trust levels, 
wherein the assigned trust level is based upon the 
50 value of at least one of the characteristics of the re- 
ceived integrity metric. 

2. Computer apparatus according to claim 1 , wherein 
the trusted device is arranged to acquire an integrity 

55 metric of the computer entity. 

3. Computer apparatus according to claim 1 or 2, 
wherein the trust level is determined by comparing 
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the value of the at least one characteristics with a 
specified value. 



18 



4. Computer apparatus according to any preceding 
claim, wherein the plurality of trust levels are deter- 5 
mined base upon a plurality of specified values as- 
sociated with a plurality of characteristics of a com- 
puter entity. 



5. Computer apparatus according to any preceding io 
claim, wherein the plurality of trust levels are deter- 
mined based upon a plurality of specified values as- 
sociated with characteristics for a plurality of com- 
puter entities. 

15 

6. A method of assigning a trust level, the method 
comprising receiving an integrity metric for a com- 
puter entity via a trusted device associated with the 
computer entity, the integrity metric having values 

for a plurality of characteristics associated with the 20 
computer entity; assigning a trust level to the com- 
puter entity from a plurality of trust levels, wherein 
the assigned trust level is based upon the value of 
at least one of the characteristics of the received 
integrity metric. 2 5 
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